home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 2135 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: in2.uu.net!insync!usenet
  2. From: bubba@insync.net (Bill Garfield)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Kickin' Setting for USR Courier
  5. Date: Sat, 20 Jan 1996 14:54:20 GMT
  6. Organization: Associated Technical Consultants
  7. Message-ID: <3100fe87.6774832@news.insync.net>
  8. References: <390_9601140747@juge.com> <4dascj$tsn@gidora.kralizec.net.au> <4de6r6$1j6@brickbat.mindspring.com> <sywx6ps56n.fsf@tiktok.cygnus.com> <4dovmi$422@usenety1.news.prodigy.com>
  9. Reply-To: bubba@insync.net
  10. NNTP-Posting-Host: line-223.insync.net
  11. X-Newsreader: Forte Agent .99c/16.141
  12.  
  13. davidsen@tmr.com (bill davidsen) wrote:
  14.  
  15. >In article <sywx6ps56n.fsf@tiktok.cygnus.com>,
  16. >Michael Meissner <meissner@cygnus.com> wrote:
  17. >
  18. >| Some of us do not like &F1's behavior (in particular, I believe that &F1 should
  19. >| have set the S register so that the modem NEVER connects to a non-error
  20. >| correcting modem -- the current behavior is to try for an error correction and
  21. >| fallback if it can't get it).
  22. >
  23. >You have a valid point, but it depends on what the user is doing. If
  24. >you don't do the fallback, the operation is "if you aren't going to
  25. >do EC I don't want to talk to you." For people who have to connect
  26. >to support BBSs which have crap modems, or people who operate
  27. >systems which accept calls from the public (I still get calls at
  28. >300) this is not reasonable policy.
  29. >
  30. >I think USR got this one right, the default is "do the best you can."
  31.  
  32. You have a valid point Bill. I'm happy with USR's defaults. The current
  33. default settings make a hellouva lot more sense than their defaults of
  34. 2-3 years ago.
  35.  
  36. Still with whatever default values there are, there will always be the
  37. need to make site-specific/application-specific settings.  On my own
  38. central site host system (minimum connect speed 9600) we have proven
  39. to our own satisfaction that non-EC connections at speeds >9600 simply
  40. are not survivable, ergo our decision to lock the host in mandatory EC
  41. configuration.
  42.  
  43. The callers having difficulty connecting then stand out like a sore
  44. thumb and end up calling our tech support line. We find that in the
  45. majority of these cases, some obscure software program has not only
  46. disabled the customer's EC settings, but has *WRITTEN* the changes to
  47. NVRAM.  Judas Priest!
  48.  
  49. Our customers receive a script file through which they connect with
  50. us. When something like the above scenario occurs, it's a simple matter
  51. to walk the customer through a script edit session and have them ENABLE
  52. their EC (assuming they can tell us what make/model of modem they have).
  53. However, unlike one of our competitors, we do not WRITE the settings to
  54. NVRAM.
  55.  
  56. Prior to LOCKING our host modems in forced EC mode, we often received 
  57. complaints about onscreen jibberish.  The FIX was to lock the host in
  58. EC, then address, one-by-one, those few customers whose modems were
  59. merely misconfigured.  This approach worked and the customers are now
  60. all happy with their connectivity to our system.
  61.  
  62.  
  63. +-----------------------------------------------------------------+
  64. |Geez....After ISDN, 28800 makes you want to get out and push!!  |
  65. |Please do not send unsolicited commercial e_mail to this address.|
  66. +-----------------------------------------------------------------+
  67.